第9章 導出プラクティス

本物の顧客参加（Real Customer Invoivement）

システムによって生活やジビネスに影響を受ける人をチームの一員にすること

四半期や週単位の計画づくりに参加でき、自由に使える予算を持っている可能性もある

顧客参加のポイントは、ニーズを持つ人とそれを満たす人が直接コミュニケーションをとり、無駄な労力をへらすことができる

本物の顧客をチームに参加できないのであれば、本物の顧客相当のプロキシを準備すること

顧客のチーム参加に以下のデメリットを聞いたことがある

参加した顧客の意見を採用すると、別の顧客の意見が流されてしまう

だが参加した顧客の問題を解決することで、まず参加した顧客への価値は提供できる。

顧客側がソフトウェア開発の混乱をしって、信頼関係に傷がはいのでは（ソーセージ工場）

そもそも現状信頼されているだろうか、信頼されていたら現在のソフトウェア開発の状況は理解しているはず

欠陥率が高くなっていても正直に申し、顧客をチームに参加させることにより、信頼関係が構築できていくもの

インクリメンタルなデプロイ（Incremental Deployment）

対応した機能や限定的な範囲でデプロイを繰り返すこと

大きな機能のデプロイで失敗した場合、人間的にも経済的にもコストが高い

チームの継続（Team Continuity）

優秀なチームは継続させること

ソフトウェアの価値は、みんなで一緒に成し遂げることで達成することができる

大きな組織はチームの需要性を無視してプログラマーをモノとして見ることがあるが、局所的には効率的になったが、組織全体の効率は低下する

チームの縮小（Shrinking Teams)

チームの能力が高まったら、仕事量を維持しながらチームの規模を少なくしていく取り組みをすること

チームを離れた人は、別のチームを作成し、小さいチームは統合する。（トヨタ生産方式のプラクティス）

全員を忙しい状況にすると、チームの改善ポイントなどの広い視点が持てる人がいなくなる

全員の等しく忙しくするのではなく、1人タスクの量を減らして改善策や検討などに検討する余裕を入れて、抜けても問題状況を作る

根本原因分析（Root-Cause Analysis）

開発後に欠陥を見つけた時には、欠陥とその原因を取り除くこと

XPでは以下の手順で対策をしていく

1. 欠陥を実証するシステムレベルの自動テストを書く。そこには期待する挙動も含める

2. 血管を再現する最小限のスコープでユニットテストを書く

3. ユニットテストを動くようにシステムを修正する

4. 欠陥を修正できたら、なぜ欠陥が生み出されたか、なぜ発見できなかったのかを見極める。今後は、同様の欠陥が再発しないように、必要な変更を加える

「5回のなぜ」を繰り返すことでステップ4の深掘りを実施できる

コードの共有（Shared Code）

チーム全員がシステムの改善作業ができる

システムの問題が、現在進行中のタスクのスコープであれば、改善に取り組む

チーム全体の責任能力がなくなると、コードの品質が落ち、チームに与える影響を考慮せずに、自分本位の変更をしてしまう

コードとテスト（Code and Tests）

コードとテストだけを永続的な成果物として保守すること

そのためのドキュメントは、コードとテストから生成すること

顧客はシステムとチームの開発費用のお金を払っている。それ以外は無駄。

単一のコードベース（Single Code Base）

ソースコードのバージョンを増やしてはいけない

どうしても分けないといけない理由がある場合は、本当にその必要があるのかを吟味し、デメリットを承知した上で対応していく

デイリーデプロイ（Daily Deployment）

ソフトウェアのリリースは毎晩行うこと。

一つの機能をリリースするまで複数のタスクをこなす必要がある場合（DBの再結成、新機能の実装、UIの実装など）は、UXに関わる以外のものは全てリリースしてしまって、再度のUIだけをリリースすればいい。

こまめにデプロイする障壁はたくさんがあるが、取り除くことができれば開発が改善される

低コストのデプロイ方法の必要性

デプロイプロセスに対しての心理的なストレス・社会的な障壁

リリースに対して料金を請求する方法がない

交渉によるスコープ契約（Ngegotiated Scope Contract）

契約の段階で期間、費用、品質は固定にして、スコープへ継続的に交渉できるようにしておく

長くて膨大な契約書を大幅に分割することができる

交渉によるスコープ契約は、あくまでソフトウェア開発に関するアドバイス。供給側と顧客の利害を一致させ、フィードバックとコミュニケーションを促進するためのもの

利用都度課金（Pay-Per-Use）

システム利用都度課金とは、ユーザーがシステムを利用するたびに課金が発生する仕組み

システム利用都度課金を導入すれば、機能に対する収益情報が次回のソフトウェア開発に活かせる

特定の機能に対する収益がわかれば、次回ストーリーと比較した収益の見積もりが見れるようになる

収益を得ている機能があれば、自動的に関連するストーリーを採用していく

今まではリリースごとに開発費用を紫原ていったが、これは得策ではないかった

顧客側は1回のリリースで多くの機能を盛り込もうとし、開発側はお金を支払いためだけの、最低限の機能しか開発をしなくなり、コミュニケーションとフィードバックが合判する

利用都度課金が難しい場合は、サブスクリプションモデルという選択肢もある。定着率を確認できたり、プランを増やしたりサポートの比重を高くする選択肢もできる